Actually the spec doesn't clarify when an endpoint template should be accepted or
not. Now, the appc/spec implementation returns only endpoints that can
be fully rendered. This means that it will also accept a template if it
doesn't contain some of the required discovery labels.

This looks good, but, trying to implement some meta discovery ideas it
will bring to unwanted endpoints.

Example 1:
Suppose I want to implement the "latest" pattern behavior:

```html
<!-- ACIs with specific version -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-{version}-{os}-{arch}.{ext}">
<!-- Latest ACIs -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-latest-{os}-{arch}.{ext}">
```

If, on discovery, I ask for the _name_, _os_ and _arch_
labels only the second template will be rendered (since the first cannot
be fully rendered due to missing _version_ label). So I achieved latest
pattern.

But if I'm asking for a specific _version_ both templates will be
rendered.

Example 2:
As an extension of the first example, suppose I want to create a global
meta discovery for all my images on example.com. So on the root of my
server I'll put some meta tags using example.com as prefix:

```html
<!-- ACIs with specific version -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-{version}-{os}-{arch}.{ext}">
<meta name="ac-discovery" content="example.com https://mirror.storage.example.com/{name}-{version}-{os}-{arch}.{ext}">
<!-- noarch ACIs -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-{version}-noarch.{ext}">
<meta name="ac-discovery" content="example.com https://mirror.storage.example.com/{name}-{version}-noarch.{ext}">
<!-- Latest ACIs -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-latest-{os}-{arch}.{ext}">
<meta name="ac-discovery" content="example.com https://mirror.storage.example.com/{name}-latest-{os}-{arch}.{ext}">
<!-- Latest noarch ACIs -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-latest-noarch.{ext}">
<meta name="ac-discovery" content="example.com https://mirror.storage.example.com/{name}-latest-noarch.{ext}">
```

With this tags I want to implement global "latest" and "noarch" patterns
and also return multiple mirrors.

If, on discovery, I ask only for the _name_ and _version_ labels the
template 3 and 4 will be rendered. So I achieved a versioned noarch pattern.

But, unfortunately, also template 5, 6, 7, and 8 will be rendered.

And, as the first example, if I'm asking for a specific _name_,
_version_, _os_ and _arch_ ALL the templates will be rendered.

Since the spec says:
```
Note that multiple `ac-discovery` tags MAY be returned for a given
prefix-match [snip] In this case, the client implementation MAY choose
which to use at its own discretion.
```

If an implementation chooses the second it can download the wrong image version.

This patch makes template matching stricter choosing only best matching templates.
Best matching templates are the one where all the templates labels can
be substituted and with the highest number of substituted labels.

With this we can obtain various patterns like latest and noarch and also
keeping the ability to return multiple mirror urls. See also the tests
added in this commit.

It also documents this behavior.

It should not BREAK many of the current meta tags implementation (it
depends on how the client uses the returned endpoints, for example rkt,
currently, only uses the first one)

Actually, if the required discovery labels doesn't contain a version
label, it'll be set to a default of "latest". This behavior isn't
documented in the spec and can create unwanted behaviors.

This patch removes this and also adds to the spec an example on how to
obtain the latest behavior without this "hidden" default.